Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wasm WIP #7

Closed
wants to merge 187 commits into from
Closed

Wasm WIP #7

wants to merge 187 commits into from

Conversation

neelance
Copy link
Owner

@neelance neelance commented Mar 8, 2018

No description provided.

@neelance neelance force-pushed the wasm-wip branch 2 times, most recently from da4e74e to 8e7bc2b Compare March 8, 2018 23:17
@neelance neelance changed the title Wasm wip Wasm WIP Mar 8, 2018
@@ -464,6 +465,9 @@ func TestZip64LargeDirectory(t *testing.T) {
if testing.Short() {
t.Skip("skipping in short mode")
}
if runtime.GOARCH == "wasm" {
t.Skip("too slow on wasm")
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I imagine we might need to quantify this and potentially include some kind of TODO for re-enabling. What order of runtime are we talking about here?

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just tested it again and it goes out of memory after a while.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add a comment explaining this here then?

@agnivade
Copy link

Great stuff. Are you planning to send a CL soon ?

@neelance neelance force-pushed the wasm-wip branch 13 times, most recently from a54cb67 to f37e5eb Compare March 28, 2018 23:36
@CryZe
Copy link

CryZe commented Mar 29, 2018

It seems like the jump labels may potentially be wrong. I'm getting jump labels like these all over the place
firefox_2018-03-29_01-41-10

that don't correlate to any actual block labels. For some reason Chrome and Firefox still validate the wasm correctly (so maybe that's correct (?)), but according to the spec this shouldn't validate
chrome_2018-03-29_01-48-31
chrome_2018-03-29_02-01-47

@kybin
Copy link

kybin commented Mar 29, 2018

It would be great if there is a post to let us know how we can build simple web site with go-wasm.

@neelance
Copy link
Owner Author

@CryZe It is jumping to the toplevel block of the function, which is the end of the function. Are you sure that the spec defines no implicit toplevel block?

@neelance
Copy link
Owner Author

@kybin Too early for that, still experimental.

@CryZe
Copy link

CryZe commented Mar 29, 2018

Huh, you are right, looks like the labels vector is initially initialized with a label for the function itself. Looks like no other wasm backend generates it like this, they all use return, but it seems correct. 👍

@kybin
Copy link

kybin commented Mar 29, 2018

Oh, OK. I might be just too excited. :)

@neelance neelance force-pushed the wasm-wip branch 3 times, most recently from cc9ec59 to 42326b1 Compare March 29, 2018 00:36
@neelance
Copy link
Owner Author

@CryZe Oops, I completely overlooked the return op. I will change it. Thanks for making me aware. 👍

@cretz
Copy link

cretz commented Mar 29, 2018

@neelance - Figured this was the best place to ask instead of issue 18892 on the Go repo itself...how much work has to be done to target non-JS WASM backends? I see JS references littered all throughout the code, though I'm sure some thought has been given to http://webassembly.org/docs/non-web/. Why does the import object have to be called js and functions called things like runtime/js.floatVal? Also, any chance at some point that the things a target architecture must implement to support go-via-wasm will be documented?

(for reference, I have a non-web backend at https://github.com/cretz/asmble, that's why I ask)

@neelance
Copy link
Owner Author

neelance commented Mar 29, 2018

@cretz Since WebAssembly does not define a common API, you have to pick something. I am initially targeting web browsers and Node.js, so using an API based on the current JS world makes sense. Inventing my own API would only create yet another API. So GOARCH=js does not necessarily mean "needs JavaScript", but rather "uses API that looks like today's JavaScript API". However, you can add other GOOS values for wasm if you don't want to implement this API.

griesemer and others added 13 commits June 12, 2018 18:55
The original fix (https://go-review.googlesource.com/c/go/+/35831)
for this issue was incorrect as it reported cycles in cases where
it shouldn't.

Instead, use a different approach: A type cycle containing aliases
is only a cycle if there are no type definitions. As soon as there
is a type definition, alias expansion terminates and there is no
cycle.

Approach: Split sprint_depchain into two non-recursive and more
easily understandable functions (cycleFor and cycleTrace),
and use those instead for cycle reporting. Analyze the cycle
returned by cycleFor before issueing an alias cycle error.

Also: Removed original fix (main.go) which introduced a separate
crash (golang#23823).

Fixes golang#18640.
Fixes golang#23823.
Fixes golang#24939.

Change-Id: Ic3707a9dec40a71dc928a3e49b4868c5fac3d3b7
Reviewed-on: https://go-review.googlesource.com/118078
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Fixes golang#25834

Change-Id: I33e58dabfd04b84dfee1a9a3796796b5d19862e7
Reviewed-on: https://go-review.googlesource.com/118295
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
…/Or8 on ARM64

ARM64 manual says it is "constrained unpredictable" if the src
and dst registers of STLXRB are same, although it doesn't seem
to cause any problem on real hardwares so far. Fix by allocating
a different register to hold the updated value for
AtomicAnd8/Or8. We do this by making the ops returns <val,mem>
like AtomicAdd, although val will not be used elsewhere.

Fixes golang#25823.

Change-Id: I735b9822f99877b3c7aee67a65e62b7278dc40df
Reviewed-on: https://go-review.googlesource.com/117976
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Wei Xiao <Wei.Xiao@arm.com>
Before this CL, if you had GOCACHE=/some/dir, then the cmd/go tests used it.
But if you were relying on the implicit behavior that GOCACHE being empty
meant an appropriate system-specific cache directory, then the cmd/go tests
ran with no cache at all, which makes them about 4X slower.

During all.bash GOCACHE is set to a fresh temporary directory and is therefore
already getting proper caching; this CL mainly helps people running 'go test cmd/go'
by hand.

Change-Id: I7c322ca79b877c1d0a3b448b95d5354fbfcba7f8
Reviewed-on: https://go-review.googlesource.com/118320
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently these two forms of layout are done in a single pass. This
makes it difficult to compress DWARF sections because that must be
done after relocations are applied, which must happen after virtual
address layout, but we can't layout the file until we've compressed
the DWARF sections.

Fix this by separating the two layout steps. In the process, we can
also unify the copy-pasted code in Link.address to compute file
offsets. Currently, each instance of this is slightly different, but
there's no reason for it to be. For example, we don't perform
PEFILEALIGN alignment on Segrodata or Selreltodata even when HeadType
== Hwindows, but it turns out it doesn't matter whether you do or
don't because these segments simply don't exist on Windows. Hence, in
the unified code path, we do this alignment for all segments.
Likewise, there are two ways of computing Fileoff:
  seg.Vaddr - prev.Vaddr + prev.Fileoff
and
  prev.Fileoff + uint64(Rnd(int64(prev.Filelen), int64(*FlagRound)))
At the moment, these always have the same value, but the latter will
continue to work after we start compressing sections on disk.

Tested by comparing test binaries for all packages in std before and
after this change for GOOS={linux,windows,darwin,plan9}. All binaries
are identical.

For golang#11799.

Change-Id: If09f28771bb4d78dd392fd58b8d7c9d5f22b0b9f
Reviewed-on: https://go-review.googlesource.com/111682
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This commit changes sys.Wasm to sys.WASM, as requested on
https://groups.google.com/forum/#!topic/golang-dev/VquDxlhjPkg

Change-Id: I30a208c34576a8bb49b9beb524203d71df8fdf1c
Reviewed-on: https://go-review.googlesource.com/118395
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Change-Id: I3a83c63f4db2e46fd96f373378a429896e93f9d1
Reviewed-on: https://go-review.googlesource.com/48861
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change-Id: I0bbb53cad9a7c464ab1cfca381128f33496813ff
Reviewed-on: https://go-review.googlesource.com/49130
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
name              old time/op   new time/op   delta
EncodeToString-4   35.5µs ± 7%   33.3µs ± 6%  -6.27%   (p=0.008 n=10+9)
DecodeString-4      120µs ± 7%    113µs ± 8%  -5.88%  (p=0.011 n=10+10)

name              old speed     new speed     delta
EncodeToString-4  231MB/s ± 8%  247MB/s ± 5%  +6.55%   (p=0.008 n=10+9)
DecodeString-4    109MB/s ± 7%  116MB/s ± 8%  +6.27%  (p=0.011 n=10+10)

Change-Id: I60bf962464179e35b1711617adbc45a822eaece5
Reviewed-on: https://go-review.googlesource.com/45876
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In an effort to help others avoid the issues I've hit due to lack of
symlink support under GOPATH, I've added a note of warning to the
Workspaces section.

I have not changed the contents of go help gopath, because on reflection
it seems this change alone may be sufficient.

Fixes golang#21320

Change-Id: Ib8969bf12cecad878e89ff66b5864bbf3caaf219
Reviewed-on: https://go-review.googlesource.com/61930
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Separated out panic handling for bimporter and importer so that
the handler can consider the current version and report a better
error.

Added new export data test for export data version 999 (created
by changing the compiler temporarily) and verifying expected
error message.

Fixes golang#25856.

Change-Id: Iaafec07b79499154ef7c007341783fa07c57f24d
Reviewed-on: https://go-review.googlesource.com/118496
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Change-Id: Iea5c705dd58f9b83fbeb0500defcc08c34716169
GitHub-Last-Rev: 35702c7
GitHub-Pull-Request: golang#25858
Reviewed-on: https://go-review.googlesource.com/118536
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change-Id: I3ac25cf1770b5ac0d36690c37615b3badd27463d
Reviewed-on: https://go-review.googlesource.com/118455
Reviewed-by: Rob Pike <r@golang.org>
suriyaa and others added 4 commits June 13, 2018 13:45
Change-Id: I9d2d25df067ca573589db5ff18296a5ec33866be
Reviewed-on: https://go-review.googlesource.com/118595
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 108156 added -cgo and -export,
but in the usage line it added -cgo and -list.
CL 117015 correctly added -export to the usage line.
All that remains is to remove -list.

Change-Id: I8cc5cfc78bc6b52080ae1b861f92620a8f18b53f
Reviewed-on: https://go-review.googlesource.com/118375
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is needed in addition to CL 110066 in order to be able to generate
Go type definitions for linux/riscv64 in the golang.org/x/sys/unix
package.

Change-Id: I4a27e6424aaea63283b55bd4f73b958b41f29d72
Reviewed-on: https://go-review.googlesource.com/118618
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The pprof tool utilizes attributes of mapping entries
such as HasFunctions to determine whether the profile
includes necessary symbol information.
If none of the attributes is set, pprof tool tries to
read the corresponding binary to use for local symbolization.
If the binary doesn't exist, it prints out error messages.

Go runtime generated profiles without any of the attributes
set so the pprof tool always printed out the error messages.
The error messages became more obvious with the new
terminal support that uses red color for error messages.

Go runtime can symbolize all Go symbols and generate
self-contained profile for pure Go program. Thus, there
is no reason for the pprof tool to look for the copy of
the binary. So, this CL sets one of the attributes
(HasFunctions) true if all PCs in samples look fully
symbolized.

For non-pure Go program, however, it's possible that
symbolization of non-Go PCs is incomplete. In this case,
we need to leave the attributes all false so pprof can attempt
to symbolize using the local copy of the binary if available.
It's hard to determine whether a mapping includes non-Go
code. Instead, this CL checks PCs from collected samples.
If unsuccessful symbolization is observed, it skips setting
the HasFunctions attribute.

Fixes golang#25743

Change-Id: I5108be45bbc37ab486d145fa03e7ce37d88fad50
Reviewed-on: https://go-review.googlesource.com/118275
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
neelance and others added 2 commits June 13, 2018 14:51
This commit changes wasm_exec.js to not depend on the existence of
performance.timeOrigin. The field is not yet supported on all
browsers, e.g. it is unavailable on Safari.

Change-Id: I6cd3834376c1c55424c29166fde1219f0d4d338f
Reviewed-on: https://go-review.googlesource.com/118617
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Like on other architectures, use rawSyscallNoError for Linux syscalls
that don't return an error and convert all applicable occurences of
RawSyscall to use it instead.

This was missed in CL 84485 because mkall.sh doesn't support
mipsx/mips64x, so add the corresponding entries as well.

Updates golang#22924

Change-Id: I762cbee0827140b9890c4a10830e0b4cd33de92f
Reviewed-on: https://go-review.googlesource.com/118655
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@neelance neelance force-pushed the wasm-wip branch 2 times, most recently from acbf401 to 19ceb7d Compare June 13, 2018 15:15
This commit adds support for JavaScript callbacks back into
WebAssembly. This is experimental API, just like the rest of the
syscall/js package. The time package now also uses this mechanism
to properly support timers without resorting to a busy loop.

JavaScript code can call into the same entry point multiple times.
The new RUN register is used to keep track of the program's
run state. Possible values are: starting, running, paused and exited.
If no goroutine is ready any more, the scheduler can put the
program into the "paused" state and the WebAssembly code will
stop running. When a callback occurs, the JavaScript code puts
the callback data into a queue and then calls into WebAssembly
to allow the Go code to continue running.

Updates golang#18892
Updates golang#25506

Change-Id: Ib8701cfa0536d10d69bd541c85b0e2a754eb54fb
1. Make import functions not use the js.Value type directly,
but only the ref field. This gives more flexibility on the Go side
for the js.Value type, which is a preparation for adding
garbage collection of js.Value.

2. Turn import functions which are methods of js.Value into
package-level functions. This is necessary to make vet happy.

Change-Id: I69959bf1fbea0a0b99a552a1112ffcd0c024e9b8
This commit enables vet/all for the js/wasm architecture. It got
skipped initially because the codebase did not fully compile yet
for js/wasm, which made vet/all fail.

startTimer and stopTimer are not needed in the syscall package.
Removed their assembly code since their Go stubs were already gone.

Change-Id: Icaeb6d903876e51ceb1edff7631f715a98c28696
Change-Id: I2f2b2d0b5bd7a59b34f108d2fd7b6ba2eb26f9c9
Change-Id: Id221e8395516d3b7227267fecacc0ef78118041c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet